Yep, I'm going to write a module called Module::Metadata::Changes, starting tomorrow.
I installed Module::Changes, but was so distressed by the cascade of dependencies that I resolved to try myself.
This namespace allows Module::Metadata::SomethingElse, so that's a plus.
I will adopt the nice suggestion of Marcel Grünauer as regards a typical content for a Perl module's Changes file. See his POD for details, or my POD-to-be.
And yes, I'll default to YAML, even though my reservations about YAML are even more soundly based than yours. See my FAQ-to-be for details.
I will be adding something like:
Upgrade:
Deploy: Yes
Reason: Security
or
Deploy: No need
Reason: Doc or test changes only.
This allows you to Do The Right Thing with:
Deploy: No
Reason: Development version.
After all, we don't want another Data::Dumper fiasco, do we :-(? Remember the uncountable millions of warning messages issued about 'Not Numeric' because V 1.21_01 I think it was, was released?
If use of YAML upsets you, please feel free to write a module with a name like XML2YAML2XML::Tiny, using YAML::Tiny and XML::Tiny. That'll allow us to ship all of:
o CHANGES
o Changes.yml
o Changes.xml
Re:I've been trying...
Ron Savage on 2008-05-02T04:31:53
$many x $thanx;
I read your contribution when it was first published, but my recent researches did not uncover it.
I assure I'll study it carefully, but the result of my work probably won't look quite the same...
Re:Cool
Ron Savage on 2008-05-02T06:10:11
Thanx for the sample.
I'll add some tests to see how I cope.
I have a basic module running, parsing my previous CHANGES files, so it's effectively a version of Module::Changes::Parser::Free.
It reads and writes YAML files, and you can get() the latest version and release.
I'll finish the updating code next, but now it's off to get ready for the Melbourne Jazz Festival tonight.
